Operator fusion management in a stream computing environment

ABSTRACT

Disclosed aspects relate to operator fusion management in a stream computing environment. A topology model which indicates a set of stream operators, a set of connections between the set of stream operators, and a set of stream operator attributes for the set of stream operators may be established. Based on the topology model, a set of operator fusion management operations to combine the set of stream operators into a set of processing elements may be determined. The set of processing elements may be constructed by performing the set of operator fusion management operations.

BACKGROUND

This disclosure relates generally to computer systems and, moreparticularly, relates to operator fusion management in a streamcomputing environment. The amount of stream computing data that needs tobe managed by enterprises is increasing. Management of stream computingenvironments may be desired to be performed as efficiently as possible.As stream computing data needing to be managed increases, the need forefficient operator fusion management in a stream computing environmentmay increase.

SUMMARY

Aspects of the disclosure relate to operator fusion management in astream computing environment. A set of stream operators of a topologymodel may be fused using a set of operator fusion management operatorsto create a set of processing elements. The set of operator fusionmanagement operations may be determined based on a variety of factors.Operator fusion management decisions may be based on deployment clustercharacteristics, user motivations, application characteristics, fusioncycle result evaluations, application load conditions or other factors.One or more components may evaluate the heuristics and factors thataffect stream operator fusion, and determine the set of operator fusionmanagement operations to combine the set of stream operators into theset of processing elements. Leveraging operator fusion managementtechniques may be associated with various benefits such as dataprocessing efficiency, stream application performance, or the like.

Disclosed aspects relate to operator fusion management in a streamcomputing environment. A topology model which indicates a set of streamoperators, a set of connections between the set of stream operators, anda set of stream operator attributes for the set of stream operators maybe established. Based on the topology model, a set of operator fusionmanagement operations to combine the set of stream operators into a setof processing elements may be determined. The set of processing elementsmay be constructed by performing the set of operator fusion managementoperations.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The drawings included in the present application are incorporated into,and form part of, the specification. They illustrate embodiments of thepresent disclosure and, along with the description, serve to explain theprinciples of the disclosure. The drawings are only illustrative ofcertain embodiments and do not limit the disclosure.

FIG. 1 illustrates an exemplary computing infrastructure to execute astream computing application according to embodiments.

FIG. 2 illustrates a view of a compute node according to embodiments.

FIG. 3 illustrates a view of a management system according toembodiments.

FIG. 4 illustrates a view of a compiler system according to embodiments.

FIG. 5 illustrates an exemplary operator graph for a stream computingapplication according to embodiments.

FIG. 6 is a flowchart illustrating a method for operator fusionmanagement in a stream computing environment, according to embodiments.

FIG. 7 shows an example system for operator fusion management in astream computing environment, according to embodiments.

FIG. 8 is a flowchart illustrating a method for operator fusionmanagement in a stream computing environment, according to embodiments.

FIG. 9 is a flowchart illustrating a method for operator fusionmanagement in a stream computing environment, according to embodiments.

FIG. 10 is a flowchart illustrating a method for operator fusionmanagement in a stream computing environment, according to embodiments.

FIG. 11 illustrates a method using a heuristic based comparatormechanism for stream operation fusion management, according toembodiments.

FIG. 12 is a diagram illustrating a table of example fusion constraintsfor stream operation fusion management, according to embodiments.

While the invention is amenable to various modifications and alternativeforms, specifics thereof have been shown by way of example in thedrawings and will be described in detail. It should be understood,however, that the intention is not to limit the invention to theparticular embodiments described. On the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

DETAILED DESCRIPTION

Aspects of the disclosure relate to operator fusion management in astream computing environment. A set of stream operators of a topologymodel (e.g., operator graph) may be fused using a set of operator fusionmanagement operators to create a set of processing elements. The set ofoperator fusion management operations may be determined based on avariety of factors (e.g., rules, heuristics). Operator fusion managementdecisions may be based on deployment cluster characteristics (e.g., sizeand number of hosts), user motivations (e.g., target number ofprocessing elements), application characteristics (e.g., developerexpressed constraints), fusion cycle result evaluations (e.g.,prediction of operator fusion outcomes), application load conditions(e.g., host resources available for processing elements) or otherfactors. A composer (e.g., fusion management engine) may evaluate theheuristics and factors that affect stream operator fusion, and determinethe set of operator fusion management operations to combine the set ofstream operators into the set of processing elements. Leveragingoperator fusion management techniques may be associated with variousbenefits such as data processing efficiency, stream applicationperformance, or the like.

Stream-based computing and stream-based database computing are emergingas a developing technology for database systems. Products are availablewhich allow users to create applications that process and querystreaming data before it reaches a database file. With this emergingtechnology, users can specify processing logic to apply to inbound datarecords while they are “in flight,” with the results available in a veryshort amount of time, often in fractions of a second. Constructing anapplication using this type of processing has opened up a newprogramming paradigm that will allow for development of a broad varietyof innovative applications, systems, and processes, as well as presentnew challenges for application programmers and database developers.

In a stream computing application, stream operators are connected to oneanother such that data flows from one stream operator to the next (e.g.,over a TCP/IP socket). When a stream operator receives data, it mayperform operations, such as analysis logic, which may change the tupleby adding or subtracting attributes, or updating the values of existingattributes within the tuple. When the analysis logic is complete, a newtuple is then sent to the next stream operator. Scalability is achievedby distributing an application across nodes by creating executables(i.e., processing elements), as well as replicating processing elementson multiple nodes and load balancing among them. Stream operators in astream computing application can be fused together to form a processingelement that is executable. Doing so allows processing elements to sharea common process space, resulting in much faster communication betweenstream operators than is available using inter-process communicationtechniques (e.g., using a TCP/IP socket). Further, processing elementscan be inserted or removed dynamically from an operator graphrepresenting the flow of data through the stream computing application.A particular stream operator may not reside within the same operatingsystem process as other stream operators. In addition, stream operatorsin the same operator graph may be hosted on different nodes, e.g., ondifferent compute nodes or on different cores of a compute node.

Data flows from one stream operator to another in the form of a “tuple.”A tuple is a sequence of one or more attributes associated with anentity. Attributes may be any of a variety of different types, e.g.,integer, float, Boolean, string, etc. The attributes may be ordered. Inaddition to attributes associated with an entity, a tuple may includemetadata, i.e., data about the tuple. A tuple may be extended by addingone or more additional attributes or metadata to it. As used herein,“stream” or “data stream” refers to a sequence of tuples. Generally, astream may be considered a pseudo-infinite sequence of tuples.

Tuples are received and output by stream operators and processingelements. An input tuple corresponding with a particular entity that isreceived by a stream operator or processing element, however, isgenerally not considered to be the same tuple that is output by thestream operator or processing element, even if the output tuplecorresponds with the same entity or data as the input tuple. An outputtuple need not be changed in some way from the input tuple.

Nonetheless, an output tuple may be changed in some way by a streamoperator or processing element. An attribute or metadata may be added,deleted, or modified. For example, a tuple will often have two or moreattributes. A stream operator or processing element may receive thetuple having multiple attributes and output a tuple corresponding withthe input tuple. The stream operator or processing element may onlychange one of the attributes so that all of the attributes of the outputtuple except one are the same as the attributes of the input tuple.

Generally, a particular tuple output by a stream operator or processingelement may not be considered to be the same tuple as a correspondinginput tuple even if the input tuple is not changed by the processingelement. However, to simplify the present description and the claims, anoutput tuple that has the same data attributes or is associated with thesame entity as a corresponding input tuple will be referred to herein asthe same tuple unless the context or an express statement indicatesotherwise.

Stream computing applications handle massive volumes of data that needto be processed efficiently and in real time. For example, a streamcomputing application may continuously ingest and analyze hundreds ofthousands of messages per second and up to petabytes of data per day.Accordingly, each stream operator in a stream computing application maybe required to process a received tuple within fractions of a second.Unless the stream operators are located in the same processing element,it is necessary to use an inter-process communication path each time atuple is sent from one stream operator to another. Inter-processcommunication paths can be a critical resource in a stream computingapplication. According to various embodiments, the available bandwidthon one or more inter-process communication paths may be conserved.Efficient use of inter-process communication bandwidth can speed upprocessing.

A streams processing job has a directed graph of processing elementsthat send data tuples between the processing elements. The processingelement operates on the incoming tuples, and produces output tuples. Aprocessing element has an independent processing unit and runs on ahost. The streams platform can be made up of a collection of hosts thatare eligible for processing elements to be placed upon. When a job issubmitted to the streams run-time, the platform scheduler processes theplacement constraints on the processing elements, and then determines(the best) one of these candidates host for (all) the processingelements in that job, and schedules them for execution on the decidedhost.

Aspects of the disclosure include a method, system and computer programproduct for operator fusion management in a stream computingenvironment. A topology model which indicates a set of stream operators,a set of connections between the set of stream operators, and a set ofstream operator attributes for the set of stream operators may beestablished. Based on the topology model, a set of operator fusionmanagement operations to combine the set of stream operators into a setof processing elements may be determined. By performing the set ofoperator fusion management operations, the set of processing elementsmay be constructed.

In embodiments, determining the set of operator fusion managementoperations based on the topology model may include using a set ofdeployment cluster characteristics. The set of deployment clustercharacteristics may include both a compute host quantity factor and acompute host size factor. In embodiments, determining the set ofoperator fusion management operations based on the topology model mayinclude using a fusion tightness factor. In embodiments, determining theset of operator fusion management operations based on the topology modelmay include using a set of application characteristics. The set ofapplication characteristics may indicate a stream operator co-locationcriterion, a stream operator ex-location criterion, a stream operatorisolation criterion, a stream operator count, and a constraintcomplexity factor. In embodiments, determining the set of operatorfusion management operations based on the topology model may includeusing a set of historical data associated with a set of parameters ofthe set of operator fusion management operations. In embodiments,determining the set of operator fusion management operations based onthe topology model may include using a deployment cluster load factorrelated to a separate stream application.

In embodiments, determining the set of operator fusion managementoperations based on the topology model may include identifying a set ofinflexible parameters with respect to the set of operator fusionmanagement operations and identifying a set of flexible parameters withrespect to the set of operator fusion management operations. A set ofinflexible parameter values for the set of inflexible parameters may beconfigured to disallow a first modification which exceeds a firstthreshold, and a set of flexible parameter values for the set offlexible parameters may be configured to allow a second modificationwithin a second threshold. In embodiments, a familial subset of the setof stream operators may be detected using the topology model. Thefamilial subset of the set of stream operators may indicate one or morestream operators that have a fusion-related mandate. In embodiments, asingle processing element that includes the familial subset of the setof stream operators may be built.

In embodiments, determining the set of operator fusion managementoperations based on the topology model may include formulating an orderof operations for the set of operator fusion management operations. Inembodiments, formulating the order of operations for the set of operatorfusion management operations may include identifying, based on aprocessing element selection factor in response to identifying a firstprocessing element to target for allocation with a first subset of theset of stream operators, a second processing element to target forallocation with a second subset of the set of stream operators. Inembodiments, determining the set of operator fusion managementoperations based on the topology model may include identifying, based ona stream operator selection factor, a subset of the set of streamoperators to allocate to a target processing element.

In embodiments, determining the set of operator fusion managementoperations based on the topology model may include computing a firstexpected performance factor for a first fusion cycle, computing a secondexpected performance factor for a second fusion cycle, comparing thefirst and second expected performance factors, and identifying, based onthe first expected performance factor exceeding the second expectedperformance factor, the first fusion cycle. In embodiments, determiningthe set of operator fusion management operations based on the topologymodel may include calculating a number of processing elements to targetusing a feature which is selected from the group consisting of a userinput, a processor proportion value, or a source-sink count. Inembodiments, determining the set of operator fusion managementoperations based on the topology model may include resolving, withrespect to an operator fusion action, a target processing element usingan element which is selected from the group consisting of a streamoperator balancing criterion to balance a number of stream operators perprocessing element, a source-sink count to fuse stream operators whichare nearer to stream limits, and a new processing element.

In embodiments, determining the set of operator fusion managementoperations based on the topology model may include ascertaining, withrespect to a target processing element, a target stream operator using acomponent which is selected from the group consisting of a set of chaincriteria which indicates to continue a chain of a subset of the set ofstream operators, a set of fusion criteria which indicates a set oftarget processing element parameters for a candidate stream operator, anumber of interconnections between the target processing element and thetarget stream operator, and achievement of a match-absence thresholdwhich indicates a deficiency of the target stream operator. Altogether,aspects of the disclosure can have performance or efficiency benefits(e.g., wear-rate, service-length, reliability, speed, flexibility, loadbalancing, responsiveness, stability, high availability, resource usage,productivity). Aspects may save resources such as bandwidth, disk,processing, or memory.

FIG. 1 illustrates one exemplary computing infrastructure 100 that maybe configured to execute a stream computing application, according tosome embodiments. The computing infrastructure 100 includes a managementsystem 105 and two or more compute nodes 110A-110D—i.e., hosts—which arecommunicatively coupled to each other using one or more communicationsnetworks 120. The communications network 120 may include one or moreservers, networks, or databases, and may use a particular communicationprotocol to transfer data between the compute nodes 110A-110D. Acompiler system 102 may be communicatively coupled with the managementsystem 105 and the compute nodes 110 either directly or via thecommunications network 120.

The communications network 120 may include a variety of types ofphysical communication channels or “links.” The links may be wired,wireless, optical, or any other suitable media. In addition, thecommunications network 120 may include a variety of network hardware andsoftware for performing routing, switching, and other functions, such asrouters, switches, or bridges. The communications network 120 may bededicated for use by a stream computing application or shared with otherapplications and users. The communications network 120 may be any size.For example, the communications network 120 may include a single localarea network or a wide area network spanning a large geographical area,such as the Internet. The links may provide different levels ofbandwidth or capacity to transfer data at a particular rate. Thebandwidth that a particular link provides may vary depending on avariety of factors, including the type of communication media andwhether particular network hardware or software is functioning correctlyor at full capacity. In addition, the bandwidth that a particular linkprovides to a stream computing application may vary if the link isshared with other applications and users. The available bandwidth mayvary depending on the load placed on the link by the other applicationsand users. The bandwidth that a particular link provides may also varydepending on a temporal factor, such as time of day, day of week, day ofmonth, or season.

FIG. 2 is a more detailed view of a compute node 110, which may be thesame as one of the compute nodes 110A-110D of FIG. 1, according tovarious embodiments. The compute node 110 may include, withoutlimitation, one or more processors (CPUs) 205, a network interface 215,an interconnect 220, a memory 225, and a storage 230. The compute node110 may also include an I/O device interface 210 used to connect I/Odevices 212, e.g., keyboard, display, and mouse devices, to the computenode 110.

Each CPU 205 retrieves and executes programming instructions stored inthe memory 225 or storage 230. Similarly, the CPU 205 stores andretrieves application data residing in the memory 225. The interconnect220 is used to transmit programming instructions and application databetween each CPU 205, I/O device interface 210, storage 230, networkinterface 215, and memory 225. The interconnect 220 may be one or morebusses. The CPUs 205 may be a single CPU, multiple CPUs, or a single CPUhaving multiple processing cores in various embodiments. In oneembodiment, a processor 205 may be a digital signal processor (DSP). Oneor more processing elements 235 (described below) may be stored in thememory 225. A processing element 235 may include one or more streamoperators 240 (described below). In one embodiment, a processing element235 is assigned to be executed by only one CPU 205, although in otherembodiments the stream operators 240 of a processing element 235 mayinclude one or more threads that are executed on two or more CPUs 205.The memory 225 is generally included to be representative of a randomaccess memory, e.g., Static Random Access Memory (SRAM), Dynamic RandomAccess Memory (DRAM), or Flash. The storage 230 is generally included tobe representative of a non-volatile memory, such as a hard disk drive,solid state device (SSD), or removable memory cards, optical storage,flash memory devices, network attached storage (NAS), or connections tostorage area network (SAN) devices, or other devices that may storenon-volatile data. The network interface 215 is configured to transmitdata via the communications network 120.

A stream computing application may include one or more stream operators240 that may be compiled into a “processing element” container 235. Thememory 225 may include two or more processing elements 235, eachprocessing element having one or more stream operators 240. Each streamoperator 240 may include a portion of code that processes tuples flowinginto a processing element and outputs tuples to other stream operators240 in the same processing element, in other processing elements, or inboth the same and other processing elements in a stream computingapplication. Processing elements 235 may pass tuples to other processingelements that are on the same compute node 110 or on other compute nodesthat are accessible via communications network 120. For example, aprocessing element 235 on compute node 110A may output tuples to aprocessing element 235 on compute node 110B.

The storage 230 may include a buffer 260. Although shown as being instorage, the buffer 260 may be located in the memory 225 of the computenode 110 or in a combination of both memories. Moreover, storage 230 mayinclude storage space that is external to the compute node 110, such asin a cloud.

The compute node 110 may include one or more operating systems. Anoperating system may be stored partially in memory 225 and partially instorage 230. Alternatively, an operating system may be stored entirelyin memory 225 or entirely in storage 230. The operating system providesan interface between various hardware resources, including the CPU 205,and processing elements and other components of the stream computingapplication. In addition, an operating system provides common servicesfor application programs, such as providing a time function.

FIG. 3 is a more detailed view of the management system 105 of FIG. 1according to some embodiments. The management system 105 may include,without limitation, one or more processors (CPUs) 305, a networkinterface 315, an interconnect 320, a memory 325, and a storage 330. Themanagement system 105 may also include an I/O device interface 310connecting I/O devices 312, e.g., keyboard, display, and mouse devices,to the management system 105.

Each CPU 305 retrieves and executes programming instructions stored inthe memory 325 or storage 330. Similarly, each CPU 305 stores andretrieves application data residing in the memory 325 or storage 330.The interconnect 320 is used to move data, such as programminginstructions and application data, between the CPU 305, I/O deviceinterface 310, storage unit 330, network interface 315, and memory 325.The interconnect 320 may be one or more busses. The CPUs 305 may be asingle CPU, multiple CPUs, or a single CPU having multiple processingcores in various embodiments. In one embodiment, a processor 305 may bea DSP. Memory 325 is generally included to be representative of a randomaccess memory, e.g., SRAM, DRAM, or Flash. The storage 330 is generallyincluded to be representative of a non-volatile memory, such as a harddisk drive, solid state device (SSD), removable memory cards, opticalstorage, Flash memory devices, network attached storage (NAS),connections to storage area-network (SAN) devices, or the cloud. Thenetwork interface 315 is configured to transmit data via thecommunications network 120.

The memory 325 may store a stream manager 134. Additionally, the storage330 may store an operator graph 335. The operator graph 335 may definehow tuples are routed to processing elements 235 (FIG. 2) for processingor stored in memory 325 (e.g., completely in embodiments, partially inembodiments).

The management system 105 may include one or more operating systems. Anoperating system may be stored partially in memory 325 and partially instorage 330. Alternatively, an operating system may be stored entirelyin memory 325 or entirely in storage 330. The operating system providesan interface between various hardware resources, including the CPU 305,and processing elements and other components of the stream computingapplication. In addition, an operating system provides common servicesfor application programs, such as providing a time function.

FIG. 4 is a more detailed view of the compiler system 102 of FIG. 1according to some embodiments. The compiler system 102 may include,without limitation, one or more processors (CPUs) 405, a networkinterface 415, an interconnect 420, a memory 425, and storage 430. Thecompiler system 102 may also include an I/O device interface 410connecting I/O devices 412, e.g., keyboard, display, and mouse devices,to the compiler system 102.

Each CPU 405 retrieves and executes programming instructions stored inthe memory 425 or storage 430. Similarly, each CPU 405 stores andretrieves application data residing in the memory 425 or storage 430.The interconnect 420 is used to move data, such as programminginstructions and application data, between the CPU 405, I/O deviceinterface 410, storage unit 430, network interface 415, and memory 425.The interconnect 420 may be one or more busses. The CPUs 405 may be asingle CPU, multiple CPUs, or a single CPU having multiple processingcores in various embodiments. In one embodiment, a processor 405 may bea DSP. Memory 425 is generally included to be representative of a randomaccess memory, e.g., SRAM, DRAM, or Flash. The storage 430 is generallyincluded to be representative of a non-volatile memory, such as a harddisk drive, solid state device (SSD), removable memory cards, opticalstorage, flash memory devices, network attached storage (NAS),connections to storage area-network (SAN) devices, or to the cloud. Thenetwork interface 415 is configured to transmit data via thecommunications network 120.

The compiler system 102 may include one or more operating systems. Anoperating system may be stored partially in memory 425 and partially instorage 430. Alternatively, an operating system may be stored entirelyin memory 425 or entirely in storage 430. The operating system providesan interface between various hardware resources, including the CPU 405,and processing elements and other components of the stream computingapplication. In addition, an operating system provides common servicesfor application programs, such as providing a time function.

The memory 425 may store a compiler 136. The compiler 136 compilesmodules, which include source code or statements, into the object code,which includes machine instructions that execute on a processor. In oneembodiment, the compiler 136 may translate the modules into anintermediate form before translating the intermediate form into objectcode. The compiler 136 may output a set of deployable artifacts that mayinclude a set of processing elements and an application descriptionlanguage file (ADL file), which is a configuration file that describesthe stream computing application. In some embodiments, the compiler 136may be a just-in-time compiler that executes as part of an interpreter.In other embodiments, the compiler 136 may be an optimizing compiler. Invarious embodiments, the compiler 136 may perform peepholeoptimizations, local optimizations, loop optimizations, inter-proceduralor whole-program optimizations, machine code optimizations, or any otheroptimizations that reduce the amount of time required to execute theobject code, to reduce the amount of memory required to execute theobject code, or both. The output of the compiler 136 may be representedby an operator graph, e.g., the operator graph 335.

The compiler 136 may also provide the application administrator with theability to optimize performance through profile-driven fusionoptimization. Fusing operators may improve performance by reducing thenumber of calls to a transport. While fusing stream operators mayprovide faster communication between operators than is available usinginter-process communication techniques, any decision to fuse operatorsrequires balancing the benefits of distributing processing acrossmultiple compute nodes with the benefit of faster inter-operatorcommunications. The compiler 136 may automate the fusion process todetermine how to best fuse the operators to be hosted by one or moreprocessing elements, while respecting user-specified constraints. Thismay be a two-step process, including compiling the application in aprofiling mode and running the application, then re-compiling and usingthe optimizer during this subsequent compilation. The end result may,however, be a compiler-supplied deployable application with an optimizedapplication configuration.

FIG. 5 illustrates an exemplary operator graph 500 for a streamcomputing application beginning from one or more sources 135 through toone or more sinks 504, 506, according to some embodiments. This flowfrom source to sink may also be generally referred to herein as anexecution path. In addition, a flow from one processing element toanother may be referred to as an execution path in various contexts.Although FIG. 5 is abstracted to show connected processing elementsPE1-PE10, the operator graph 500 may include data flows between streamoperators 240 (FIG. 2) within the same or different processing elements.Typically, processing elements, such as processing element 235 (FIG. 2),receive tuples from the stream as well as output tuples into the stream(except for a sink—where the stream terminates, or a source—where thestream begins). While the operator graph 500 includes a relatively smallnumber of components, an operator graph may be much more complex and mayinclude many individual operator graphs that may be statically ordynamically linked together.

The example operator graph shown in FIG. 5 includes ten processingelements (labeled as PE1-PE10) running on the compute nodes 110A-110D. Aprocessing element may include one or more stream operators fusedtogether to form an independently running process with its own processID (PID) and memory space. In cases where two (or more) processingelements are running independently, inter-process communication mayoccur using a “transport,” e.g., a network socket, a TCP/IP socket, orshared memory. Inter-process communication paths used for inter-processcommunications can be a critical resource in a stream computingapplication. However, when stream operators are fused together, thefused stream operators can use more rapid communication techniques forpassing tuples among stream operators in each processing element.

The operator graph 500 begins at a source 135 and ends at a sink 504,506. Compute node 110A includes the processing elements PE1, PE2, andPE3. Source 135 flows into the processing element PE1, which in turnoutputs tuples that are received by PE2 and PE3. For example, PE1 maysplit data attributes received in a tuple and pass some data attributesin a new tuple to PE2, while passing other data attributes in anothernew tuple to PE3. As a second example, PE1 may pass some received tuplesto PE2 while passing other tuples to PE3. Tuples that flow to PE2 areprocessed by the stream operators contained in PE2, and the resultingtuples are then output to PE4 on compute node 110B Likewise, the tuplesoutput by PE4 flow to operator sink PE6 504. Similarly, tuples flowingfrom PE3 to PE5 also reach the operators in sink PE6 504. Thus, inaddition to being a sink for this example operator graph, PE6 could beconfigured to perform a join operation, combining tuples received fromPE4 and PE5. This example operator graph also shows tuples flowing fromPE3 to PE7 on compute node 110C, which itself shows tuples flowing toPE8 and looping back to PE7. Tuples output from PE8 flow to PE9 oncompute node 110D, which in turn outputs tuples to be processed byoperators in a sink processing element, for example PE10 506.

Processing elements 235 (FIG. 2) may be configured to receive or outputtuples in various formats, e.g., the processing elements or streamoperators could exchange data marked up as XML documents. Furthermore,each stream operator 240 within a processing element 235 may beconfigured to carry out any form of data processing functions onreceived tuples, including, for example, writing to database tables orperforming other database operations such as data joins, splits, reads,etc., as well as performing other data analytic functions or operations.

The stream manager 134 of FIG. 1 may be configured to monitor a streamcomputing application running on compute nodes, e.g., compute nodes110A-110D, as well as to change the deployment of an operator graph,e.g., operator graph 132. The stream manager 134 may move processingelements from one compute node 110 to another, for example, to managethe processing loads of the compute nodes 110A-110D in the computinginfrastructure 100. Further, stream manager 134 may control the streamcomputing application by inserting, removing, fusing, un-fusing, orotherwise modifying the processing elements and stream operators (orwhat tuples flow to the processing elements) running on the computenodes 110A-110D.

Because a processing element may be a collection of fused streamoperators, it is equally correct to describe the operator graph as oneor more execution paths between specific stream operators, which mayinclude execution paths to different stream operators within the sameprocessing element. FIG. 5 illustrates execution paths betweenprocessing elements for the sake of clarity.

FIG. 6 is a flowchart illustrating a method 600 for operator fusionmanagement in a stream computing environment, according to embodiments.Aspects of method 600 relate to determining a set of operator fusionmanagement operations to combine the set of stream operators into a setof processing elements based on a topology model. The topology model mayindicate the set of stream operators, a set of connections between theset of stream operators, and a set of stream operator attributes for theset of stream operators. The operator fusion management operations maybe determined based on a number of factors and heuristics (e.g.,deployment cluster characteristics, user motivations, applicationcharacteristics, fusion cycle result evaluations, application loadconditions). Leveraging operator fusion management techniques may beassociated with benefits including data processing efficiency and streamapplication performance. The method 600 may begin at block 601.

In embodiments, the establishing, the determining, the constructing, andother steps described herein may each occur in an automated fashionwithout user intervention (e.g., using automated computing machinery,fully machine-driven without manual stimuli) at block 604. Inembodiments, the establishing, the determining, the constructing, andother steps described herein may be carried out by an internal operatorfusion management module maintained in a persistent storage device of acomputing node that hosts the streaming application containing the setof stream operators. In certain embodiments, the establishing, thedetermining, the constructing, and other steps described herein may becarried out by an external operator fusion management module (e.g.,composer, fusion management engine) hosted by a remote computing deviceor server (e.g., accessible via a subscription, usage-based, or otherservice model). In this way, aspects of operator fusion management in astream computing environment may be performed using automated computingmachinery without manual action. Other methods of performing the stepsdescribed herein are also possible.

At block 610, a topology model may be established. The topology modelmay indicate a set of stream operators, a set of connections between theset of stream operators, and a set of stream operator attributes for theset of stream operators. Generally, establishing can include organizing,arranging, instantiating, or otherwise setting up the topology model.The topology model may include a representation of the arrangement ofthe various elements (e.g., connections, nodes, operators, tuples) thatmake up a stream computing application. As an example, the topologymodel may include an operator graph. In embodiments, establishing thetopology model may include arranging a set of stream operators orprocessing elements in the operating graph of a streaming application,and configuring the stream operators and processing elements forhandling and processing of a set of tuples. The set of stream operatorsmay include data processing units configured to perform operations(e.g., logic-based analysis, attribute modification) on data (e.g.,tuples) as part of a stream computing application. The set of streamoperators may operate on incoming tuples to produce output tuples. Inembodiments, the topology model may indicate a set of connectionsbetween the set of stream operators. The set of connections may includelinks, couplings, bonds, or other indications of the relationshipbetween one or more stream operators of the set of stream operators. Forinstance, the set of connections may indicate which stream operators arelinked to which other stream operators of the topology model, whether astream operator is located upstream or downstream with respect toanother stream operator, frequency of data traffic between two streamoperators, or the like. The topology model may also indicate a set ofstream operator attributes for the set of stream operators. The set ofstream operator attributes may include information regarding thecharacteristics, properties, or other aspects of the set of streamoperators. For example, the set of stream operator attributes mayindicate the type or function (e.g., join, ingest, sort, functor) of thestream operators, performance characteristics (e.g., tuple throughputrate) of the set of stream operators, fusion compatibility factors(e.g., low compatibility with a first operator type, high compatibilitywith a second operator type) and other properties of the set of streamoperators. Other methods of establishing the topology model are alsopossible.

Consider the following example. An integrated development environment(IDE) for an in-development stream application may include an operatinggraph. A group of stream operators may be identified for placement inthe operating graph of the streaming application (e.g., stream operatorsthat facilitate performance of the stream application). The group ofidentified stream operators may be placed in the operating graph. TheIDE for the stream application may include an information summary toolthat displays the stream operators that have been placed in theoperating graph. In embodiments, the IDE may indicate a connection treethat displays the stream operators that are connected to a particularstream operator, as well as information regarding communication betweenconnected stream operators (e.g., tuple transmission rate, communicationfrequency, upstream/downstream location). In certain embodiments, eachstream operator of the set of stream operators may be associated with astream operator profile that includes a set of stream operatorattributes (e.g., performance characteristics, fusioncompatibility/constraints) describing the operation and function thatstream operator performs in the stream application. Other methods ofestablishing the topology model are also possible.

At block 630, a set of operator fusion management operations to combinethe set of stream operators into a set of processing elements may bedetermined. Generally, determining can include formulating, identifying,computing, calculating, resolving, selecting, or ascertaining the set ofoperator fusion management operations. In embodiments, determining theset of operator fusion management operations may include selecting asubset of the set of stream operators for fusion, as well as identifyinga particular operator fusion management operation for the subset ofstream operators. The set of operator fusion management operations mayinclude one or more routines, sub-routines, processes, or procedures forcombining a plurality of stream operators into a processing element. Inembodiments, the operator fusion management operations may be based onthe topology model. For instance, the topology model may indicate one ormore fusion factors (e.g., via the set of stream operators, set ofconnections, or set of stream operator attributes) such as deploymentcluster characteristics (e.g., size and number of hosts), usermotivations (e.g., target number of processing elements), applicationcharacteristics (e.g., developer expressed constraints), fusion cycleresult evaluations (e.g., prediction of operator fusion outcomes),application load conditions (e.g., host resources available forprocessing elements) or other factors that affect operator fusion. Inembodiments, determining the set of operator fusion managementoperations may include performing a series of fusion cycles. The fusioncycles may include simulated fusion operations performed with differentfusion parameters (e.g., different stream operators, fusion constraints,fusion rule sets). In embodiments, the results of a number of fusioncycles may be compared, and a set of operator fusion managementoperations associated with positive impacts (e.g., stream applicationperformance, desirable processing element configuration) with respect tothe stream computing environment may be determined. Other methods ofdetermining the set of operator fusion management operations arepossible.

Consider the following example. A topology model may include 8 streamoperators selected as targets for operator fusion management operations.Each stream operator may be associated with different performancecharacteristics (e.g., tuple throughput rate), fusion constraints (e.g.,other operators it may not be fused with, must be fused with), and otherattributes that affect the fusion process. As described herein, a seriesof fusion cycles may be performed to determine the set of operatorfusion management operations. In embodiments, it may be detected (e.g.,based on a user input) that the 8 stream operators should be fused into3 processing elements. Additionally, it may be identified that 3 of the8 stream operators are part of a subset of stream operators that must befused together (e.g., they are part of the same fusable unit/familialsubset). Accordingly, a series of fusion cycles may be generated, whereeach fusion cycle is configured to simulate a different operator fusionscenario (e.g., fuse operators so that all resultant processing elementshave roughly the same tuple throughput rate, fuse all operators thatshare a particular attribute together, put all connected operators onthe same processing element). In response to performing the series offusion cycles, the results of each simulated fusion cycle may beevaluated, and the set of operator fusion management operations (e.g.,associated with positive impacts for the stream computing environment)may be determined. For instance, a set of operator fusion managementoptions that place the subset of 3 stream operators and one additionalstream operator on a first processing element, and the other 4processing elements split evenly between two more processing elementsmay be detected to achieve the fusions constraints for the set of streamoperators. Other methods of determining the set of operator fusionmanagement operations are also possible.

At block 650, the set of processing elements may be constructed byperforming the set of operator fusion management operations. Generally,constructing can include structuring, building, formulating, producing,composing, or otherwise creating the set of processing elements. Inembodiments, constructing the set of processing elements may includeselecting one or more stream operators of the set of stream operators tocombine together into a set of processing elements. As described herein,the set of processing elements may be constructed by performing the setof operator fusion management operations. For instance, constructing mayinclude combining the set of processing elements in accordance with theresults of the fusion composition cycles. In certain embodiments,constructing the set of processing elements may include dynamically(e.g., in real-time, on-the-fly) altering the job submission process forthe stream application to account for the instantaneous runtimespecifics of the deployment configuration, the stream application'soperational characteristics, and parameters specified by the jobsubmitter. As an example, constructing the set of processing elementsmay include fusing a string of operators beginning with a sourceoperator and ending with a sink operator (e.g., group of connectedoperators) into a single processing element. Other methods ofconstructing the set of processing elements are also possible.

Consider the following example. A topology model may include 5 streamoperators A, B, C, D, E selected as targets for operator fusionmanagement operations. The topology model may be associated with a setof fusion constraints that affect which operators may or may not befused together (e.g., placed on the same processing operator). The setof fusion constraints may include hard constraints (e.g., inflexibleparameters that must be achieved by the operator fusion managementoperations) and soft constraints (e.g., flexible parameters that shouldbe prioritized to the degree that they do not interfere with hardconstraints). For instance, the set of fusion constraints may include ahard constraint that stream operators C and E must be fused together, ahard constraint that A and C cannot be fused together, a soft constraintto fuse stream operators A and E together, and an additional softconstraint to place connected operators together on the same processingelement. In embodiments, stream operators C and D may be connected. Inembodiments, the topology model may include a specification (e.g., userspecified parameter) that the set of operator fusion managementoperations should create 2 resultant processing elements. Accordingly,as described herein, the fusion constraints of the topology model may beanalyzed to determine a set of operator fusion management operations tocombine the set of stream operators into a set of processing elements.As an example, a set of operator fusion management operations may bedetermined that places stream operators C, D, and E together on thefirst processing element, and A and B together on the second processingelement. As such, both hard constraints are achieved, as well as thesoft constraint to place connected operators on the same processingelement (e.g., the soft constraint to place operators A and E togethermay interfere with the hard constraint to put operators E and C togetheras well as the hard constraint that operators A and C may not be placedtogether, and thus may be disregarded). The stream operators may beplaced as indicated by the set of operator fusion management operations,and fused to construct the first and second processing elements. Othermethods of constructing the set of processing elements are alsopossible.

In certain embodiments, a stream of tuples is received at block 680. Thestream of tuples may be processed by a plurality of processing elements(e.g., stream operators) operating on a set of compute nodes (e.g., in astream application environment). The stream of tuples may be receivedconsistent with the description herein including FIGS. 1-12.Current/future processing by the plurality of processing elements may beperformed consistent with the description herein including FIGS. 1-12.The set of compute nodes may include a shared pool of configurablecomputing resources. For example, the set of compute nodes can be apublic cloud environment, a private cloud environment, or a hybrid cloudenvironment. In certain embodiments, each of the set of compute nodesare physically separate from one another.

In certain embodiments, the stream of tuples is processed at block 690.The stream of tuples may be processed by the plurality of processingelements operating on the set of compute nodes. The stream of tuples maybe processed consistent with the description herein including FIGS.1-12. In embodiments, stream operators operating on the set of computenodes may be utilized to process the stream of tuples. Processing of thestream of tuples by the plurality of processing elements may providevarious flexibilities for stream operator management. Overall flow(e.g., data flow) may be positively impacted by utilizing the streamoperators.

Method 600 concludes at block 699. Aspects of method 600 may provideperformance or efficiency benefits for operator fusion management in astream computing environment. For example, aspects of method 600 mayhave positive impacts with respect to determining and constructing a setof processing elements using a set of operator fusion managementoperations (e.g., reliability, speed, flexibility, resource usage,productivity). Altogether, leveraging operator fusion host managementtechniques may be associated with benefits including data processingefficiency and stream application performance.

FIG. 7 shows an example system 700 for operator fusion management in astream computing environment, according to embodiments. Aspects of FIG.7 are directed toward determining the set of operator fusion managementoperations based on a variety of factors that influence operator fusion(e.g., deployment cluster characteristics, user motivations, applicationcharacteristics, fusion cycle result evaluations, application loadconditions). The example system 700 may include an operator fusionmanagement system 710. The operator fusion management system 710 mayinclude an establishing module 720 configured to establish a topologymodel, a determining module 725 configured to determine a set ofoperator fusion management operations based on the topology model, and aconstructing module 730 configured to construct a set of processingelements by performing the set of operator fusion management operations.The operator fusion management system 710 may be communicativelyconnected with a first module management system 750 and a second modulemanagement system 770 that each include one or more modules forperforming other operations related to operator fusion management.

In embodiments, determining the set of operator fusion managementoperations may include using a set of deployment cluster characteristicsat module 751. The set of deployment cluster characteristics may includeboth a compute host quantity factor and a compute host size factor.Generally, the set of deployment cluster characteristics may includeinformation regarding the attributes and properties of the host computenodes to which the set of processing elements may be deployed. Forinstance, the set of deployment cluster characteristics may include acompute host quantity factor that indicates the number of host computenodes available to receive deployment of the set of processing elements,and a compute host size factor that indicates the number of processingelements that may be maintained by each available host compute node. Asanother example, the set of deployment cluster characteristics mayinclude data regarding the computing resources available for use byhosted processing elements, the type/function of past/currently hostedprocessing elements, and other information. Aspects of the descriptionrelate to the recognition that, in embodiments, the set of deploymentcluster characteristics may be used to determine the set of operatorfusion management operations. For instance, based on the number ofavailable host compute nodes (e.g., as indicated by the set ofdeployment cluster characteristics), it may be desirable to increase ordecrease the number of processing elements created from fusion. Othermethods of using the set of deployment cluster characteristics are alsopossible.

In embodiments, determining the set of operator fusion managementoperations may include using a fusion tightness factor at module 752.Generally, the fusion tightness factor may be a representation of thenumber of stream operators that are placed on a given processingelement. Processing elements that contain a relatively high number ofstream operators may be considered to be “tightly” fused, whileprocessing elements that contain a relatively low number of streamoperators may be considered to be “lightly” fused. In embodiments, thefusion tightness factor may be expressed as a ratio of the storage spaceoccupied by stream operators with respect to the total storage spaceavailable for stream operators on a processing element (e.g., 4.1gigabytes of 5 total gigabytes), or as the number of stream operators ona processing element with respect to the maximum number of streamoperators that may be placed on that processing element (e.g., 7 streamoperators out of 10 total placement slots). In embodiments, the fusiontightness factor may be associated with a target number of processingelements to be created by the set of operator fusion managementoperations. As an example, a request (e.g., received from a user) to“fuse tightly” may prioritize creation of a fewer number of processingelements with a greater number of stream operators per processingelement, while a request to “fuse lightly” may prioritize creation of agreater number of processing elements with a fewer number of streamoperators per processing element. In certain embodiments, a user mayspecify a target number of processing elements (e.g., 5), and a desiredfusion tightness factor, and the set of operator fusion managementoperations may be determined such that the resultant processing elementsachieve the specified criteria. Other methods of using the fusiontightness factor are also possible.

In embodiments, determining the set of operator fusion managementoperations may include using a set of application characteristics atmodule 753. The set of application characteristics may include a streamoperator co-location criterion, a stream operator ex-location criterion,a stream operator isolation criterion, a stream operator count, and aconstraint complexity factor. Generally, the set of applicationcharacteristics may include criteria or constraints that govern whichstream operators may or may not be placed together (e.g., on the sameprocessing element). In embodiments, the stream operator co-locationcriterion may indicate one or more stream operators that must be fusedtogether on the same processing element. In embodiments, the streamoperator ex-location criterion may indicate one or more stream operatorsthat must not be fused together on the same processing element. Inembodiments, the stream operator isolation criterion may indicate one ormore stream operators that may not be placed together with any otherstream operators on the same processing element (e.g., must be placedalone on a processing element). In embodiments, the constraintcomplexity factor may be an indication of the degree of complexity ofthe constraints specified with respect to operator fusion (e.g., largenumber of constraints, difficult to resolve). Other types of applicationcharacteristics are also possible.

In embodiments, determining the set of operator fusion managementoperations may include using a set of historical data associated with aset of parameters of the set of operator fusion management operations atmodule 754. Generally, the set of historical data can include theresults of one or more stream operator fusion simulations (e.g.,simulated/predicted outcomes of different operator fusion arrangementsusing different heuristics/rules/constraints). As described herein,aspects of the disclosure relate to performing a series of streamoperator fusion cycles such that each cycle applies/prioritizesdifferent fusion constraints, and the results of each fusion cycle maybe collected and maintained as a set of historical data. The collectedhistorical data for the series of stream operator fusion cycles may beevaluated and used to determine the set of operator fusion managementoperations for the set of stream operators. In certain embodiments,aspects of the disclosure relate to the recognition that the constraintsgoverning operator fusion may be too restrictive, such that a suitableset of operator fusion management operations cannot be resolved (e.g.,as indicated by the set of historical data). Accordingly, in response tofailing to resolve/determine the set of operator fusion managementoperations, the constraints may be relaxed (e.g., loosened, slackened)to facilitate determination of the set of operator fusion managementoperations. For instance, the set of historical data may be analyzed todetermine a past constraint configuration that allowed for resolution ofthe operator fusion management operations. Other methods of using theset of historical data are also possible.

In embodiments, determining the set of operator fusion managementoperations may include using a deployment cluster load factor related toa separate stream application at module 755. Generally, the deploymentcluster load factor can include a representation of the workloadconfiguration of a streaming application. For instance, the deploymentcluster load factor may indicate the amount of computing resources(e.g., processing resources, memory resources, storage resources,network bandwidth) in use by a streaming application, the relativeutilization level of the streaming application (e.g., by a user, virtualmachine, other application), or other representation of the amount oftasks/operations/work managed by the streaming application. Aspects ofthe disclosure relate to the recognition that, in certain embodiments,one or more potential host compute nodes may host a streamingapplication associated with a heavy workload, limiting the resourcesavailable for hosting additional processing elements. Accordingly, thenumber of processing elements to be constructed by the set of operatorfusion management operations may be based on the deployment cluster loadfactor. As an example, in a situation in which a number of potentialhost compute nodes are overloaded (e.g., associated with heavy workloadsas indicated by the deployment cluster load factor), it may be desirableto fuse a lesser number of processing elements that may be more easilyplaced on less loaded host compute nodes. Other methods of using thedeployment cluster load factor are also possible.

In embodiments, determining the set of operator fusion managementoperations may include identifying a set of parameters at module 756.Generally, identifying can include detecting, discovering, recognizing,receiving, or otherwise ascertaining the set of parameters. The set ofparameters may include a set of inflexible parameters with respect tothe set of operator fusion management operations and a set of flexibleparameters with respect to the set of operator fusion managementoperations. The set of inflexible parameters may include hardconstraints or required criteria regarding stream operator fusion thatmust be achieved by the set of operator fusion management operations inorder to qualify as a valid fusion configuration for the set ofprocessing elements. As an example, the set of inflexible parameters mayinclude a criterion that specifies two operators to be fused together,or a requirement that indicates that all processing elements include atleast 3 stream operators. The set of flexible parameters may includesoft constraints or recommended criteria regarding stream operatorfusion. The set of flexible parameters may be associated with a range oftarget values, or a weighting value that indicates the relative degreeof importance of the parameter (e.g., parameters with high weightingvalues may be prioritized over parameters with low weighting values). Asan example, the set of flexible parameters may include a criterion thatspecifies two operators that may not be desirable to be fused together,or a range of target tuple throughput rates (e.g., between 500 and 800tuples per second) for the resultant processing elements. Inembodiments, the set of parameters may be detected by an operator fusionmanagement module based on the system properties of potential hostcompute nodes and the performance characteristics of the streamingapplication. In embodiments, the set of parameters may be received by auser or administrator of the stream computing environment. Other methodsof identifying the set of parameters are also possible.

In embodiments, the set of parameters may be configured at module 757.Generally, configuring may include establishing, modifying, altering,instantiating, setting, or revising the set of parameters. Inembodiments, configuring the set of parameters may include configuring aset of inflexible parameter values for the set of inflexible parametersto disallow a first modification which exceeds a first threshold. Theset of inflexible parameter values may include one or more numbers,figures, or symbols that define a setting or property of a particularinflexible parameter. In embodiments, the set of inflexible parametervalues may define a fixed attribute or limit (e.g., fixed resource usagelevel, tuple throughput rate) of a parameter, such that attemptedmodifications that exceed a first threshold are denied (e.g., refused,prevented, forbidden). In embodiments, configuring the set of parametersmay include configuring a set of flexible parameter values (e.g.,numbers, figures, or symbols that define a setting or property of aparticular flexible parameter). The set of flexible parameter values maydefine a malleable or adjustable attribute of a parameter, such thatmodifications within a second threshold are allowed. Consider an examplesituation in which a set of inflexible parameter values specify that theminimum acceptable tuple throughput rate (e.g., first threshold) for afirst processing element is 700 tuples per second. The addition orremoval of a stream operator that would decrease the tuple throughputrate of the processing element below 700 tuples may be prevented. Asanother example, a set of flexible parameter values may designate atarget tuple throughput rate (e.g., second threshold) for a secondprocessing element is between 400 and 800 tuples per second.Accordingly, the addition or removal of stream operators to the secondprocessing element may be permitted provided the tuple throughput rateremains between 400 and 800 tuples per second. Other methods ofconfiguring the set of parameters are also possible.

In embodiments, determining the set of operator fusion managementoperations may include formulating an order of operations for the set ofoperator fusion management operations at module 758. Generally,formulating can include ordering, sequencing, ascertaining, ordetermining the order of operations for the set of fusion managementoperations. The order of operations for the set of fusion managementoperations may include an arrangement of the type and sequence ofanalysis processes to be performed on the topology model (e.g., todetermine how to fuse the set of stream operators). As described herein,formulating the order of operations may include generating a series offusion cycles for the set of stream operators. For instance, a fusioncycle in which a first set of fusion constraints (e.g., desired fusiontightness factor of 4 operators per processing element, inflexibleex-location criterion for a subset of operators) are applied to the setof stream operators may be scheduled as a first cycle, and a fusioncycle in which a second set of fusion constraints (e.g., targetprocessing element number of 6, flexible co-location criterion for asubset of operators, threshold throughput rate of at least 400 tuplesper second) are applied to the set of stream operators may be scheduledas a second cycle of the series of fusion cycles. As described herein,the series of fusion cycles may be performed based on the formulatedorder of operations, and result data (e.g., historical data) from eachcycle may be gathered and used to facilitate determination of the set ofoperator fusion management operations. Other methods of formulating theorder of operations for the set of fusion management operations are alsopossible.

In embodiments, a second processing element to target for allocationwith a second subset of the set of stream operators may be identified atmodule 759. The second processing element may be identified based on aprocessing element selection factor in response to identifying a firstprocessing element to target for allocation with a first subset of theset of stream operators. Generally, identifying can include detecting,selecting, recognizing, ascertaining, or determining the secondprocessing element. Aspects of the disclosure relate to the recognitionthat the processing elements selected for receiving deployment of streamoperators may be identified based on the properties of other processingelements of the stream computing environment. In embodiments, theprocessing element selection factor may include a set of guidelines,specifications, or other criteria that govern which processing elementsmay be included in the set of operator fusion management operations. Forinstance, the processing element selection factor may indicate thatstream operators should be placed on the processing elements that havethe fewest number of deployed stream operators (e.g., fill processingelements starting with the emptiest). As such, in response to placing afirst stream operator on a first processing element, the set ofprocessing elements may be analyzed to ascertain a second processingelement that currently hosts the fewest (e.g., number below a threshold)number of stream operators, and the second processing element may beselected for allocation of a second stream operator. Other methods ofidentifying a processing element based on a processing element selectionfactor are also possible.

In embodiments, determining the set of operator fusion managementoperations may include identifying a subset of the set of streamoperators to allocate to a target processing element based on a streamoperator selection factor at module 760. Generally, identifying caninclude detecting, selecting, recognizing, ascertaining, or determiningthe subset of the set of stream operators to allocate to a targetprocessing element. In embodiments, aspects of the disclosure relate toselecting the stream operators for placement on a processing elementbased on the stream operators already located on the processing element,characteristics of the processing element or stream operator (e.g.,type, function, system resource usage requirements, performanceproperties) and other factors. In embodiments, the stream operatorselection factor may include a set of guidelines, specifications, orother criteria that govern which stream operators may be selected forplacement on one or more processing elements. For instance, the streamoperator selection factor may indicate that stream operators that sharea type (e.g., join) may be placed on a particular processing element,stream operators with a tuple throughput rate above a threshold valuemay be prioritized for placement on a processing element, or specifyother requirements for stream operator selection. In certainembodiments, the stream operator selection factor may designate both asource operator and a sink operator of the topology model, and specifythat the stream elements located between the source operator and sinkoperator be fused together on the same processing element. Other methodsof identifying a subset of the set of stream operators based on a streamoperator selection factor are also possible.

In embodiments, the set of operator fusion management operations mayinclude one or more methods of consecutive operator placement (e.g.,stream operator chaining). The consecutive operator placement methodsmay designate one or more strategies for successive fusion of the set ofstream operators. In embodiments, the consecutive operator placementmethod may include a breadth-first operation. The breadth-firstoperation may specify simultaneous distribution of the stream operatorson multiple processing elements (e.g., spreading out stream operators onseparate processing elements). For instance, the breadth-first operationmay be used to maintain a balance of the number of stream operators oneach processing element. In embodiments, the consecutive operatorplacement method may include a depth-first operation. The depth-firstoperation may specify concentrated placement of stream operators on asingle subset of processing elements until completion (e.g., storagespace allocated for placement of stream operators is filled). Othermethods of consecutive operator placement are also possible.

In embodiments, determining the set of operator fusion managementoperations may include a fusion cycle performance evaluation at module771. As described herein, aspects of the disclosure relate to performinga series of fusion cycles (e.g., fusion composition cycles) to determinethe set of operator fusion management operations. The series of fusioncycles may include simulated fusion operations performed with differentfusion parameters (e.g., different stream operators, fusion constraints,fusion rule sets). In embodiments, a first expected performance factorfor a first fusion cycle and a second expected performance factor for asecond fusion cycle may be computed (e.g., calculated, formulated,derived, determined). The first and second expected performance factorsmay include comprehensive, quantitative representations of theefficiency, productivity, or overall effectiveness of the candidateoperator fusion management operations simulated by the first and secondfusion cycles. As an example, the first and second expected performancefactors may be expressed as integers between 1 and 100, wherein greaterintegers (e.g., 85) represent greater performance and lower integers(e.g., 13) represent lesser performance. In embodiments, computing thefirst and second expected performance factors may include collectingtrial results for the first and second fusion cycles, and evaluating thetrial results with respect to a set of metrics (e.g., criteria, rubric).For instance, in certain embodiments, the first expected performancefactor may be computed to be 73 and the second expected performancefactor may be computed to be 38.

In embodiments, the first and second expected performance factors may becompared (e.g., contrasted, correlated, investigated). Comparing thefirst and second expected performance factors may include examining thefirst and second expected performance factors with respect to oneanother to ascertain a relationship between the magnitude of the firstand second expected performance factors (e.g., first expectedperformance factor exceeds the second expected performance factor).Based on the comparison between the first and second expectedperformance factors, a fusion cycle corresponding to the greaterexpected performance factor may be selected. For instance, referring tothe example described herein, in response to comparing the first andsecond expected performance factors and determining that the firstexpected performance factor of 73 exceeds the second expectedperformance factor of 38, the first fusion cycle may be identified.Accordingly, as described herein, a set of operator fusion managementoperations indicated by the first fusion cycle may be determined forconstruction of the set of processing elements.

In embodiments, a familial subset of the set of stream operators may bedetected using the topology model at module 772. Generally, detectingcan include sensing, discovering, recognizing, or otherwise ascertainingthe familial subset of the set of stream operators. The familial subsetmay include one or more stream operators that are associated with afusion-related mandate (e.g., directive, command, instruction). Thefusion-related mandate may designate that the one or more streamoperators must be fused together on the same processing element (e.g.,co-located). In embodiments, one or more stream operators of thetopology model may be marked with a tag or other identifier thatindicates that they are part of a particular familial subset. Inembodiments, a single processing element that includes the familialsubset of the set of stream operators may be built at module 773.Building can include assembling, combining, fusing, or creating thesingle processing element. In embodiments, building may includeallocating the familial subset to a particular processing element andfusing the familial subset with the processing element. As an example, afamilial subset that includes 4 connected operators may be allocated andfused together to form a single processing element. Other methods ofdetecting the familial subset and building the single processing elementincluding the familial subset are also possible.

In embodiments, determining the set of operator fusion managementoperations may include calculating a number of processing elements totarget using a feature at module 774. The feature may include auser-input, a processor proportion value, or a source-sink count.Generally, calculating can include computing, formulating, ascertaining,or determining the number of processing elements to target using thefeature. In embodiments, the user-input feature may include a user(e.g., stream computing environment administrator) designated number ofprocessing elements (e.g., 10 processing elements). In embodiments, theprocessor proportion value may include a specified amount of processingresources allocated for use by the set of processing elements (e.g., 3Gigahertz). In embodiments, the source-sink count may be a designatedlimit for the number of source and sink operators that may be located ona single processing element (e.g., maximum of 6 source and sinkoperators). In embodiments, calculating the number of processingelements to target using the feature may include monitoring the set ofprocessing elements and detecting one or more triggering events (e.g.,lack of resources, surplus storage space) that correspond to one or morefeatures. Other types of features are also possible.

In embodiments, determining the set of operator fusion managementoperations may include resolving a target processing element using anelement at module 775. The element may include a stream operatorbalancing criterion to balance a number of stream operators perprocessing element, a source-sink count to fuse stream operators whichare nearer to stream limits, or a new processing element. Generally,resolving can include selecting, ascertaining, choosing, or determiningthe element with respect to an operator fusion action. In embodiments,the stream operator balancing criterion may include a placementrequirement that specifies that stream operators should be placed onthose processing elements that have the fewest stream operators (e.g., 9stream operators placed one by one on 3 empty processing elements,resulting in 3 stream operators per processing element). The source-sinkcount to fuse stream operators may include a placement requirement thatspecifies that the stream operators located at the endpoints (e.g.,source and sink operators) of the topology model be prioritized forplacement on processing elements (e.g., start at the topology modelendpoints and work toward the middle). In embodiments, the newprocessing element (e.g., brand new, rookie) may include an unused,empty processing element configured for receiving allocation of one ormore stream operators (e.g., selected in response to a shortage ofexisting processing elements). Other types of elements for resolving thetarget processing element are also possible.

In embodiments, determining the set of operator fusion managementoperations may include ascertaining a target stream operator using acomponent at module 776. Generally, determining can include selecting,identifying, choosing, or determining the target stream operator. Inembodiments, the component may include a set of chain criteria, a set offusion criteria, a number of interconnections, or a match-absencethreshold. The set of chain criteria may indicate to continue a chain ofa subset of the set of stream operators. For instance, the set of chaincriteria may specify to prioritize placement of one or more streamoperators that are connected to or share properties/attributes withstream operators that are already placed on a particular processingelement (e.g., in response to placing 3 of 4 connected operators on afirst processing element, prioritize placement of the 4th connectedoperator to the same processing element). In embodiments, the set offusion criteria may indicate a set of target processing elementparameters for a candidate stream operator. As an example, the set offusion criteria may include requirements (e.g., minimum/maximum resourcerequirements) of the processing element that must be achieved by astream operator in order for the stream operator to be placed on theprocessing element. The number of interconnections may indicate thequantity of interconnections between the target processing element andthe target stream operator. For instance, processing elements and streamoperators that share a greater number of communication connections(e.g., network communication ports, input/output terminals) may beassociated with a reduced need for inter-communication between separateprocessing elements (e.g., resulting in performance benefits). Inembodiments, the match-absence threshold may indicate a deficiency ofthe target stream operator. As an example, a stream operator that doesnot match the fusion constraints specified by the set of operator fusionmanagement operations may be considered to achieve the match-absencethreshold (e.g., an operator with significant resource requirements thatprevents placement on any available processing element). Other types ofcomponents for ascertaining the target stream operator are alsopossible.

FIG. 8 is a flowchart illustrating a method 800 for operator fusionmanagement in a stream computing environment, according to embodiments.Aspects of method 800 relate to a composing flow for managing streamoperator configuration and processing element fusion using a number ofcomposing cycles (e.g., fusion cycles). Aspects of method 800 maysubstantially correspond with embodiments described herein andillustrated in the FIGS. 1-12. The composing cycles may include a seriesof iterative, simulated fusion operations performed with differentfusion parameters (e.g., different stream operators, fusion constraints,fusion rule sets). As described herein, the results of a number ofcomposing cycles may be compared, and a set of operator fusionmanagement operations associated with positive impacts (e.g., streamapplication performance, desirable processing element configuration)with respect to the stream computing environment may be determined.Leveraging operator fusion management techniques may be associated withbenefits including data processing efficiency and stream applicationperformance. The method 800 may begin at block 801.

At block 810, a topology model may be built. In embodiments, thetopology model may include an operator graph including a set of streamoperators (e.g., topology nodes) and connections between them, togetherwith related attributes and properties of the stream computingenvironment. The topology model may include a set of fusing (e.g.,placement) constraints, as well as additional information such asweighted connections to indicate connections or stream operators thatmay be assigned greater priority. At block 820, a familial subset may bedetermined. As described herein, a familial subset may include one ormore stream operators that are designated to be treated as a unit (e.g.,co-located, placed for fusion on the same processing element). Inembodiments, a feasibility check operation may be performed to verifythat the topology (e.g., arrangement of elements of the topology model)achieves a solvability threshold (e.g., a fusion arrangement thatachieves the specified fusion constraints can be generated). As anexample, two stream operators that are designated as both co-located andex-located may represent a conflict that fails to achieve thesolvability threshold (e.g., requirement to place the stream operatorsseparately conflicts with the simultaneous requirement to place thestream operators together).

At block 830, a composing cycle may be determined. Determining thecomposing cycles may include receiving a composing script string thatincludes instructions defining the number of composing cycles to beperformed, as well as the set of heuristics (e.g., fusion constraints)to be applied for each cycle of the series of composing cycles. Inembodiments, the composing script may be generated by the streamcomputing environment, input by a user/stream environment administrator,or selected from a template. For instance, an example composing scriptmay include “ComposingScript=ACDB1#2#_ACD1%50%*.” In embodiments, 2cycles may be requested (e.g., “_” separates the first and secondcycles), and the letters may represent specific heuristics to be usedfor each cycle (e.g., fusion constraints ACDB for the first cycle andfusion constraints ACD1 for the second cycle). The numeral “1” may beused for selecting which stream operator (e.g., familial subset) is tobe placed in a particular processing element. The “#2#” symbol may beused for determining the starting number of containers (e.g., #n# or%50%). The “*” symbol may be used to evaluate which fusion configurationis appropriate given the set of fusion constraints (e.g., specialcharacters may represent various fusion configuration evaluationheuristics). As such, different fusion constraints may be defined foreach composing cycle to evaluate a variety of candidate fusionconfigurations. As an example, a first composing cycle may use anaggressive set of fusion constraints that must all be achieved (e.g., toachieve the solvability threshold). In the event that all of the fusionconstraints are achieved, this fusion configuration may be used. In theevent that the aggressive set of fusion constraints are not achieved, amore relaxed set of fusion constraints may be used for subsequentcycles. In certain embodiments, the fusion constraints and composingscript for a set of composing cycles may be dynamically modified basedon the results of a previous composing cycle, an analysis of thetopology model (e.g., on-the-fly modifications/updates), host computenode configuration information, and administrator input. Other methodsof determining the composing cycles are also possible.

At block 840, the composing cycles may be performed. In embodiments,performing the composing cycles may include applying the fusionconstraints and heuristics defined by the composing string. The fusionconstraints may be applied to establish the specified number ofprocessing elements, as well as select the target processing elementsand familial subsets for fusion. As described herein, performing thecomposing cycles may include simulating fusion operations for the set ofstream operators based on the defined fusion constraints, and collectinginformation regarding the performance of the fusion configuration ofeach composing cycle. At block 850, the method 800 may check whether anyscheduled composing cycles remain. In the event that other composingcycles remain, the method 800 may return to block 840 to performadditional composing cycles. In the event that no other composing cyclesremain, the method 800 may proceed to block 860. At block 860, theresult data for each composing cycle may be evaluated, and one or morecomposing cycles that achieve performance and efficiency thresholds maybe selected. The method 800 may conclude at block 899.

FIG. 9 is a flowchart illustrating a method 900 for operator fusionmanagement in a stream computing environment, according to embodiments.Aspects of method 900 relate to performing a number of composing cycles(e.g., fusion cycles) to determine operator fusion management operationsfor combining a set of stream operators into a set of processingelements. Aspects of method 900 may substantially correspond withembodiments described herein and illustrated in the FIGS. 1-12. Thecomposing cycles may include a series of iterative, simulated fusionoperations performed with different fusion parameters (e.g., differentstream operators, fusion constraints, fusion rule sets). As describedherein, the results of a number of composing cycles may be compared, anda set of operator fusion management operations associated with positiveimpacts (e.g., stream application performance, desirable processingelement configuration) with respect to the stream computing environmentmay be determined. Leveraging operator fusion management techniques maybe associated with benefits including data processing efficiency andstream application performance. The method 900 may begin at block 901.

At block 910, a number of processing elements may be determined. Thenumber of processing elements may represent a target number ofprocessing elements to create using the set of operator fusionmanagement operations. In embodiments, the number of processing elementsmay be specified by a user or stream computing environmentadministrator, determined based on an amount of available systemresources (e.g., available processing resources, memory resources), ordetermined based on a number of source/sink operators in the topologymodel. In certain embodiments, the number of processing elements may beadjusted downward to remove unused (e.g., empty processing elements), oradjusted upward if the fusion constraints cannot be achieved with thecurrent number of processing elements. Other methods of determining thenumber of processing elements are also possible.

At block 920, a next processing element to target for fusing may beselected. In embodiments, the next processing element may be selectedbased on which processing element has the lower number of streamoperators (e.g., to spread out/balance the number of stream operatorsper processing element). In embodiments, the next processing element maybe selected based on which processing element has the greater number ofsource or sink operators (e.g., to create fusion sets that start at theendpoints of the topology model and work toward the middle). In theevent that there are remaining stream operators to be assigned to aprocessing element but no available processing elements, a newprocessing element may be deployed to facilitate stream operatorallocation. Other methods of selecting a next processing element totarget for fusing are also possible.

At block 930, a familial subset for the target processing element may beselected. In embodiments, the familial subset may be selected based onthe fusion constraints specified by the composing string. For instance,the processing element must achieve the hard constraints (e.g.,inflexible parameters) required for receiving placement of the familialsubset (e.g., ex-location, co-location, isolation). In embodiments, thefamilial subset may be selected based on which familial subset has thegreater number of shared inter-connections between the familial subsetand the processing element (e.g., to reduce the need forinter-communication between processing elements). Other methods ofselecting the familial subset for a target processing element are alsopossible.

At block 940, the composing cycles may be performed. As describedherein, performing the composing cycles may include simulating fusionoperations for the set of stream operators and familial subsets based onthe defined fusion constraints, and collecting information regarding theperformance of the fusion configuration of each composing cycle. Atblock 950, the method 900 may check whether any familial subsets remainthat have not undergone a composing cycle. In the event that otherfamilial subsets remain, the method 900 may return to block 940 toperform additional composing cycles for the remaining familial subsets.In the event that no other familial subsets remain, the method 900 mayproceed to block 960. In response to verifying that no familial subsetsremain, at block 960, the target processing element may be marked ascomplete (e.g., fused, no longer open to receive stream operatorplacement). At block 970, the result data for each composing cycle maybe collected and returned for evaluation. The method 900 may conclude atblock 999.

FIG. 10 is a flowchart illustrating a method 1000 for operator fusionmanagement in a stream computing environment, according to embodiments.Aspects of method 1000 relate to a method for consecutive operatorplacement (e.g., stream operating chaining) for placement of a set ofstream operators on a set of processing elements (e.g., for fusion).Aspects of method 1000 may substantially correspond with embodimentsdescribed herein and illustrated in the FIGS. 1-12. Leveraging operatorfusion management techniques may be associated with benefits includingdata processing efficiency and stream application performance. Themethod 1000 may begin at block 1001.

At block 1010, a processing element may be selected. In embodiments, theprocessing element may be selected to receive placement of one or morestreaming elements (e.g., familial subsets). As described herein, theprocessing element may be selected based on the number of familialsubsets hosted by the processing element, the number of source/sinkoperators, fusion constraints, user input, or other factors. At block1020, a familial subset for the processing element may be selected. Thefamilial subset may be selected based on the number of sharedinterconnections between the familial subset and the processing element,fusion constraints (e.g., ex-location, co-location) as well as othercriteria. At block 1030, the method 1000 may verify whether chaincontinuation rules are selected for the given placement operation. Inthe event that there are no chain continuation rules selected, themethod 1000 may proceed to block 1060. In the event that chaincontinuation rules are selected, the method 1000 may proceed to block1040.

At block 1040, a familial subset for chain continuation may be selected.In embodiments, the familial subset for chain continuation may beselected based on a set of chain continuation rules that specify howfamilial subsets should be placed on the set of processing elements. Forexample, the set of chain continuation rules may specify a breadth-firstplacement method for distribution of the stream operators on multipleprocessing elements (e.g., spreading out stream operators on separateprocessing elements) or a depth-first placement method for concentratedplacement of stream operators (e.g., bundle related stream operators ona single processing element until full). In embodiments, the chaincontinuation rules may be indicated by the set of fusion constraints. Atblock 1050, the method 1000 may perform a check to see whether or notthe chain operation should be continued (e.g., whether or not unplacedfamilial subsets remain, chain continuation rules specify chaintermination). In the event that the chain is not to be continued, themethod 1000 may return to block 1010 (e.g., to begin for anotherprocessing element). In the event that the chain is to be continued, themethod 1000 may proceed to block 1060. At block 1060, it may bedetermined whether or not the processing element (e.g., selected atblock 1010) is complete. If the processing element is not complete, themethod 1000 may return to block 1040 to select additional familialsubsets for chain continuation. If the processing element is complete,the method 1000 may return to block 1010 to restart the method for a newprocessing element. The method 1000 may conclude at block 1099.

FIG. 11 illustrates a method 1100 using a heuristic based comparatormechanism for stream operation fusion management, according toembodiments. Aspects of method 1100 to using a heuristic basedcomparator mechanism to select the fusable units (e.g., familialsubsets, stream operators) for placement on a specified processingelement using a defined list of comparative heuristics (e.g., fusionconstraints). The Fusable Unit Comparator 1110 may be generated with atarget Composed Processing element. The Fusable Unit Comparator 1110 mayinclude a “compare(FusableUnit1,FusableUnit2)” operation configured totake two fusable units as parameters to compare with respect to thetarget processing element. In embodiments, the compare operation may beconfigured to return one or more of 4 possible outcomes including a nullresult (e.g., neither fusable unit matches the processing element), anegative number (e.g., indicating that the first fusable unit is abetter match/more compatible for the processing element), zero (e.g.,indicating that both fusable units are equally matches with respect tocompatibility for the processing element), or a positive number (e.g.,indicating that the second fusible unit is the better match/morecompatible for the processing element). The compare operation may beconfigured to compare the fusable units using an associated list ofFusable Unit Compare Rules 1120. The Fusable Unit Compare rules mayrepresent sub-rules that are called in order by the Fusable UnitComparator to evaluate the selected fusable units. For instance, if azero is returned (e.g., selected fusable units are equally compatiblewith respect to the processing element), the Fusable Unit Comparator maycontinue down the list of sub-rules until a non-zero result is arrivedat. As examples, the list of sub-rules may include a“MostConnectionsWith” sub-rule (e.g., to evaluate the number ofconnections between the fusable unit and the processing element) and a“Check Compatibility” sub-rule (e.g., to evaluate compatibility betweenthe processing element and the selected fusable units). Other methods ofusing the heuristic based comparator mechanism are also possible.

FIG. 12 is a diagram illustrating a table 1200 of example fusionconstraints for stream operation fusion management, according toembodiments. Aspects of the table 1200 relate to a set of exampleheuristics for governing which stream operators may be placed togetheron processing elements for fusion. Other fusion constraints beyond thoseshown in table 1200 are also possible. For example, the set of operatorfusion management operations may include using rules for processingelement identification related to a count of fused nodes (e.g.,1_fewerFusedNodes, 2_moreFusedNodes+) or a connection factor (e.g.,3_more Connections+, 4_moreDownstreamConnections+,5_moreUpstreamConnections+, 6_fewerConnections+,7_fewerDownstreamConnections+, 8_fewerUpstreamConnections+). The set ofoperator fusion management operations may include using rules for streamoperator identification related to various connections or components(e.g., B_moreAnyConnectionsWith, C_hasSourceNode, D_hasSinkNode,E_moreDownstreamConnectionsWith, F_moreUpstreamConnectionsWith,G_moreAnyConnectionsWithAnybody, H_moreFusedNodes, I_lessFusedNodes+,J_moreSinkNodes+, K_moreSourceNodes+). In embodiments, the set ofoperator fusion management operations may include using rules for chaincontinuation related to connections (e.g., M_hasAnyConnectionWith,N_hasDownstreamConnectionWith, O_hasUpDownstreamConnectionWith) or rulesfor fusion cycle result evaluation related to connections, processingelement count, or operations per processing element (e.g.,W_fewerInterConnections, X_closerToTargetPeCount, andY_SmallerDeltaOpsPerPe+). In embodiments, the set of fusionconstraints/rules described herein may be implemented within theFusableUnitCompareRule_CheckCompatibility operation (e.g., shown in FIG.11) or specified within composing strings. Other types of rules andfusion constraints are also possible.

In addition to embodiments described above, other embodiments havingfewer operational steps, more operational steps, or differentoperational steps are contemplated. Also, some embodiments may performsome or all of the above operational steps in a different order. Inembodiments, operational steps may be performed in response to otheroperational steps. The modules are listed and described illustrativelyaccording to an embodiment and are not meant to indicate necessity of aparticular module or exclusivity of other potential modules (orfunctions/purposes as applied to a specific module).

In the foregoing, reference is made to various embodiments. It should beunderstood, however, that this disclosure is not limited to thespecifically described embodiments. Instead, any combination of thedescribed features and elements, whether related to differentembodiments or not, is contemplated to implement and practice thisdisclosure. Many modifications and variations may be apparent to thoseof ordinary skill in the art without departing from the scope and spiritof the described embodiments. Furthermore, although embodiments of thisdisclosure may achieve advantages over other possible solutions or overthe prior art, whether or not a particular advantage is achieved by agiven embodiment is not limiting of this disclosure. Thus, the describedaspects, features, embodiments, and advantages are merely illustrativeand are not considered elements or limitations of the appended claimsexcept where explicitly recited in a claim(s).

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

Embodiments according to this disclosure may be provided to end-usersthrough a cloud-computing infrastructure. Cloud computing generallyrefers to the provision of scalable computing resources as a serviceover a network. More formally, cloud computing may be defined as acomputing capability that provides an abstraction between the computingresource and its underlying technical architecture (e.g., servers,storage, networks), enabling convenient, on-demand network access to ashared pool of configurable computing resources that can be rapidlyprovisioned and released with minimal management effort or serviceprovider interaction. Thus, cloud computing allows a user to accessvirtual computing resources (e.g., storage, data, applications, and evencomplete virtualized computing systems) in “the cloud,” without regardfor the underlying physical systems (or locations of those systems) usedto provide the computing resources.

Typically, cloud-computing resources are provided to a user on apay-per-use basis, where users are charged only for the computingresources actually used (e.g., an amount of storage space used by a useror a number of virtualized systems instantiated by the user). A user canaccess any of the resources that reside in the cloud at any time, andfrom anywhere across the Internet. In context of the present disclosure,a user may access applications or related data available in the cloud.For example, the nodes used to create a stream computing application maybe virtual machines hosted by a cloud service provider. Doing so allowsa user to access this information from any computing system attached toa network connected to the cloud (e.g., the Internet).

Embodiments of the present disclosure may also be delivered as part of aservice engagement with a client corporation, nonprofit organization,government entity, internal organizational structure, or the like. Theseembodiments may include configuring a computer system to perform, anddeploying software, hardware, and web services that implement, some orall of the methods described herein. These embodiments may also includeanalyzing the client's operations, creating recommendations responsiveto the analysis, building systems that implement portions of therecommendations, integrating the systems into existing processes andinfrastructure, metering use of the systems, allocating expenses tousers of the systems, and billing for use of the systems.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

While the foregoing is directed to exemplary embodiments, other andfurther embodiments of the invention may be devised without departingfrom the basic scope thereof, and the scope thereof is determined by theclaims that follow. The descriptions of the various embodiments of thepresent disclosure have been presented for purposes of illustration, butare not intended to be exhaustive or limited to the embodimentsdisclosed. Many modifications and variations will be apparent to thoseof ordinary skill in the art without departing from the scope and spiritof the described embodiments. The terminology used herein was chosen toexplain the principles of the embodiments, the practical application ortechnical improvement over technologies found in the marketplace, or toenable others of ordinary skill in the art to understand the embodimentsdisclosed herein.

What is claimed is:
 1. A computer-implemented method for operator fusionmanagement in a stream computing environment, the method comprising:establishing a topology model which indicates: a set of streamoperators, a set of connections between the set of stream operators, anda set of stream operator attributes for the set of stream operators;determining, based on the topology model, a set of operator fusionmanagement operations to combine the set of stream operators into a setof processing elements, wherein determining, based on the topologymodel, the set of operator fusion management operations includes using aset of deployment cluster characteristics, and wherein the set ofdeployment cluster characteristics includes both a compute host quantityfactor and a compute host size factor; detecting, using the topologymodel, a familial subset of the set of stream operators which indicatesone or more stream operators that have a fusion-related mandate;building a single processing element that includes the familial subsetof the set of stream operators; constructing, by performing the set ofoperator fusion management operations, the set of processing elements,wherein the establishing, the determining, and the constructing eachoccur in an automated fashion without user intervention; receiving astream of tuples to be processed by the set of processing elementsoperating on a pool of compute hosts; and processing, using the set ofprocessing elements operating on the pool of compute hosts, the streamof tuples.